System and method for electrical boot-device-reset signals

ABSTRACT

Systems and methods for providing accelerated loading of operating system and application programs upon system boot or application launch are disclosed. In one aspect, a method for providing accelerated loading of an operating system comprises the steps of: maintaining a list of boot data used for booting a computer system; preloading the boot data upon initialization of the computer system; and servicing requests for boot data from the computer system using the preloaded boot data. In another aspect, a method for providing accelerated launching of an application program comprises the steps of: maintaining a list of application data associated with an application program; preloading the application data upon launching the application program; and servicing requests for application data from a computer system using the preloaded application data.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/530,974, filed on Nov. 3, 2014, which is a continuation of U.S.patent application Ser. No. 13/118,122, filed on May 27, 2011, now U.S.Pat. No. 8,880,862, which is a continuation of U.S. patent applicationSer. No. 11/551,211, filed on Oct. 19, 2006, now U.S. Pat. No.8,112,619, which is a continuation of U.S. patent application Ser. No.09/776,267, filed on Feb. 2, 2001, now U.S. Pat. No. 7,181,608, whichclaims the benefit of U.S. Provisional Application Ser. No. 60/180,114,filed on Feb. 3, 2000, all of which are fully incorporated herein byreference in their entirety.

BACKGROUND 1. Technical Field

The present invention relates generally to systems and methods forproviding accelerated loading of operating system and applicationprograms upon system boot or application launch and, more particularly,to data storage controllers employing lossless and/or lossy datacompression and decompression to provide accelerated loading ofoperating systems and application programs.

2. Description of the Related Art

Modern computers utilize a hierarchy of memory devices. To achievemaximum performance levels, modern processors utilize onboard memory andon board cache to obtain high bandwidth access to both program and data.Limitations in process technologies currently prohibit placing asufficient quantity of onboard memory for most applications. Thus, inorder to offer sufficient memory for the operating system(s),application programs, and user data, computers often use various formsof popular off-processor high speed memory including static randomaccess memory (SRAM), synchronous dynamic random access memory (SDRAM),synchronous burst static ram (SBSRAM). Due to the prohibitive cost ofthe high-speed random access memory, coupled with their powervolatility, a third lower level of the hierarchy exists for non-volatilemass storage devices.

Furthermore, mass storage devices offer increased capacity and fairlyeconomical data storage. Mass storage devices (such as a “hard disk”)typically store the operating system of a computer system, as well asapplications and data and rapid access to such data is critical tosystem performance. The data storage and retrieval bandwidth of massstorage devices, however, is typically much less as compared with thebandwidth of other elements of a computing system. Indeed, over the lastdecade, although computer processor performance has improved by at leasta factor of 50, magnetic disk storage performance has only improved by afactor of 5. Consequently, memory storage devices severely limit theperformance of consumer, entertainment, office, workstation, servers,and mainframe computers for all disk and memory intensive operations.

The ubiquitous Internet combined with new multimedia applications hasput tremendous emphasis on storage volumetric density, storage massdensity, storewidth, and power consumption. Specifically, storagedensity is limited by the number of bits that are encoded in a massstorage device per unit volume. Similarly mass density is defined asstorage bits per unit mass. Storewidth is the data rate at which thedata may be accessed. There are various ways of categorizing storewidthin terms, several of the more prevalent metrics include sustainedcontinuous storewidth, burst storewidth, and random access storewidth,all typically measured in megabytes/sec. Power consumption iscanonically defined in terms of power consumption per bit and may bespecified under a number of operating modes including active (while datais being accessed and transmitted) and standby mode. Hence one fairlyobvious limitation within the current art is the need for even morevolume, mass, and power efficient data storage.

Magnetic disk mass storage devices currently employed in a variety ofhome, business, and scientific computing applications suffer fromsignificant seek-time access delays along with profound read/write datarate limitations. Currently the fastest available disk drives supportonly a sustained output data rate in the tens of megabytes per seconddata rate (MB/sec). This is in stark contrast to the modern PersonalComputer's Peripheral Component Interconnect (PCI) Bus's low end 32bit/33 Mhz input/output capability of 264 MB/sec and the PC's internallocal bus capability of 800 MB/sec.

Another problem within the current art is that emergent high performancedisk interface standards such as the Small Computer Systems Interface(SCSI-3), Fibre Channel, AT Attachment U1traDMA/66/100, Serial StorageArchitecture, and Universal Serial Bus offer only higher data transferrates through intermediate data buffering in random access memory. Theseinterconnect strategies do not address the fundamental problem that allmodern magnetic disk storage devices for the personal computermarketplace are still limited by the same typical physical mediarestrictions. In practice, faster disk access data rates are onlyachieved by the high cost solution of simultaneously accessing multipledisk drives with a technique known within the art as data striping andredundant array of independent disks (RAID).

RAID systems often afford the user the benefit of increased databandwidth for data storage and retrieval. By simultaneously accessingtwo or more disk drives, data bandwidth may be increased at a maximumrate that is linear and directly proportional to the number of disksemployed. Thus another problem with modern data storage systemsutilizing RAID systems is that a linear increase in data bandwidthrequires a proportional number of added disk storage devices.

Another problem with most modern mass storage devices is their inherentunreliability. Many modern mass storage devices utilize rotatingassemblies and other types of electromechanical components that possessfailure rates one or more orders of magnitude higher than equivalentsolid-state devices. RAID systems employ data redundancy distributedacross multiple disks to enhance data storage and retrieval reliability.In the simplest case, data may be explicitly repeated on multiple placeson a single disk drive, on multiple places on two or more independentdisk drives. More complex techniques are also employed that supportvarious trade-offs between data bandwidth and data reliability.

Standard types of RAID systems currently available include RAID Levels0, 1, and 5. The configuration selected depends on the goals to beachieved. Specifically data reliability, data validation, datastorage/retrieval bandwidth, and cost all play a role in defining theappropriate RAID data storage solution. RAID level 0 entails pure datastriping across multiple disk drives. This increases data bandwidth atbest linearly with the number of disk drives utilized. Data reliabilityand validation capability are decreased. A failure of a single driveresults in a complete loss of all data. Thus another problem with RAIDsystems is that low cost improved bandwidth requires a significantdecrease in reliability.

RAID Level 1 utilizes disk mirroring where data is duplicated on anindependent disk subsystem. Validation of data amongst the twoindependent drives is possible if the data is simultaneously accessed onboth disks and subsequently compared. This tends to decrease databandwidth from even that of a single comparable disk drive. In systemsthat offer hot swap capability, the failed drive is removed and areplacement drive is inserted. The data on the failed drive is thencopied in the background while the entire system continues to operate ina performance degraded but fully operational mode. Once the data rebuildis complete, normal operation resumes. Hence, another problem with RAIDsystems is the high cost of increased reliability and associateddecrease in performance.

RAID Level 5 employs disk data striping and parity error detection toincrease both data bandwidth and reliability simultaneously. A minimumof three disk drives is required for this technique. In the event of asingle disk drive failure, that drive may be rebuilt from parity andother data encoded on disk remaining disk drives. In systems that offerhot swap capability, the failed drive is removed and a replacement driveis inserted. The data on the failed drive is then rebuilt in thebackground while the entire system continues to operate in a performancedegraded but fully operational mode. Once the data rebuild is complete,normal operation resumes.

Thus another problem with redundant modern mass storage devices is thedegradation of data bandwidth when a storage device fails. Additionalproblems with bandwidth limitations and reliability similarly occurwithin the art by all other forms of sequential, pseudo-random, andrandom access mass storage devices. These and other limitations withinthe current art are addressed by the present invention.

SUMMARY OF THE INVENTION

The present invention is directed to systems and methods for providingaccelerated loading of operating system and application programs uponsystem boot or application launch and, more particularly, to datastorage controllers employing lossless and/or lossy data compression anddecompression to provide accelerated loading of operating systems andapplication programs.

In one aspect of the present invention, a method for providingaccelerated loading of an operating system comprises the steps of:maintaining a list of boot data used for booting a computer system;preloading the boot data upon initialization of the computer system; andservicing requests for boot data from the computer system using thepreloaded boot data. The boot data may comprise program code associatedwith an operating system of the computer system, an application program,and a combination thereof. In a preferred embodiment, the boot data isretrieved from a boot device and stored in a cache memory device.

In another aspect, the method for accelerated loading of an operatingsystem comprises updating the list of boot data during the boot process.The step of updating comprises adding to the list any boot datarequested by the computer system not previously stored in the listand/or removing from the list any boot data previously stored in thelist and not requested by the computer system.

In yet another aspect, the boot data is stored in a compressed format onthe boot device and the preloaded boot data is decompressed prior totransmitting the preloaded boot data to the requesting system.

In another aspect, a method for providing accelerated launching of anapplication program comprises the steps of maintaining a list ofapplication data associated with an application program; preloading theapplication data upon launching the application program; and servicingrequests for application data from a computer system using the preloadedapplication data.

In yet another aspect, a boot device controller for providingaccelerated loading of an operating system of a host system comprises: adigital signal processor (DSP); a programmable logic device, wherein theprogrammable logic device is programmed by the digital signal processorto (i) instantiate a first interface for operatively interfacing theboot device controller to a boot device and to (ii) instantiate a secondinterface for operatively interfacing the boot device controller to thehost system; and a non-volatile memory device, for storing logic codeassociated with the DSP, the first interface and the second interface,wherein the logic code comprises instructions executable by the DSP formaintaining a list of boot data used for booting the host system,preloading the boot data upon initialization of the host system, andservicing requests for boot data from the host system using thepreloaded boot data. The boot device controller further includes a cachememory device for storing the preloaded boot data.

The present invention is realized due to recent improvements inprocessing speed, inclusive of dedicated analog and digital hardwarecircuits, central processing units, (and any hybrid combinationsthereof), that, coupled with advanced data compression and decompressionalgorithms are enabling of ultra high bandwidth data compression anddecompression methods that enable improved data storage and retrievalbandwidth.

These and other aspects, features and advantages, of the presentinvention will become apparent from the following detailed descriptionof preferred embodiments that is to be read in connection with theaccompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a data storage controller according to oneembodiment of the present invention;

FIG. 2 is a block diagram of a data storage controller according toanother embodiment of the present invention;

FIG. 3 is a block diagram of a data storage controller according toanother embodiment of the present invention;

FIG. 4 is a block diagram of a data storage controller according toanother embodiment of the present invention;

FIG. 5 is a block diagram of a data storage controller according toanother embodiment of the present invention;

FIGS. 6a and 6b comprise a flow diagram of a method for initializing adata storage controller according to one aspect of the presentinvention;

FIGS. 7a and 7b comprise a flow diagram of a method for providingaccelerated loading of an operating system and/or application programsupon system boot, according to one aspect of the present invention;

FIGS. 8a and 8b comprise a flow diagram of a method for providingaccelerated loading of application programs according to one aspect ofthe present invention;

FIG. 9 is a diagram of an exemplary data compression system that may beemployed in a data storage controller according to the presentinvention; and

FIG. 10 is a diagram of an exemplary data decompression system that maybe employed in a data storage controller according to the presentinvention;

FIG. 11 is a high-level block diagram of a boot management circuitaccording to an embodiment of the present invention;

FIG. 12 illustrates timing diagrams of a boot process according to oneaspect of the present invention implementing the boot management circuitof FIG. 11 in a legacy computer system;

FIG. 13 illustrates timing diagrams of a boot process according to oneaspect of the present invention implementing the boot management circuitof FIG. 11 in a non-legacy computer system;

FIGS. 14a and 14b respectively comprise flow diagrams of a “cold” and“warm” boot process according to one aspect of the present invention;

FIG. 15 is a schematic diagram of a boot management circuit according toan embodiment of the present invention; and

FIG. 16 is a timing diagram illustrating the waveforms at various nodesin the diagram of FIG. 15.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

In the following description, it is to be understood that systemelements having equivalent or similar functionality are designated withthe same reference numerals in the Figures. It is to be furtherunderstood that the present invention may be implemented in variousforms of hardware, software, firmware, or a combination thereof.Preferably, the present invention is implemented on a computer platformincluding hardware such as one or more central processing units (CPU) ordigital signal processors (DSP), a random access memory (RAM), andinput/output (I/O) interface(s). The computer platform may also includean operating system, microinstruction code, and dedicated processinghardware utilizing combinatorial logic or finite state machines. Thevarious processes and functions described herein may be either part ofthe hardware, microinstruction code or application programs that areexecuted via the operating system, or any combination thereof.

It is to be further understood that, because some of the constituentsystem components described herein are preferably implemented assoftware modules, the actual system connections shown in the Figures maydiffer depending upon the manner in that the systems are programmed. Itis to be appreciated that special purpose microprocessors, dedicatedhardware, or any combination thereof may be employed to implement thepresent invention. Given the teachings herein, one of ordinary skill inthe related art will be able to contemplate these and similarimplementations or configurations of the present invention.

I. System Architectures

The present invention is directed to data storage controllers thatprovide increased data storage/retrieval rates that are not otherwiseachievable using conventional disk controller systems and protocols tostore/retrieve data to/from mass storage devices. The concept of“accelerated” data storage and retrieval was introduced in copendingU.S. application Ser. No. 09/266,394, filed Mar. 11, 1999, entitled“System and Methods For Accelerated Data Storage and Retrieval,” nowU.S. Pat. No. 6,601,104, and copending U.S. application Ser. No.09/481,243 filed Jan. 11, 2000, entitled “System and Methods ForAccelerated Data Storage and Retrieval,” now U.S. Pat. No. 6,604,158,both of which are commonly assigned and incorporated herein byreference. In general, as described in the above-incorporatedapplications, “accelerated” data storage comprises receiving a digitaldata stream at a data transmission rate which is greater that than thedata storage rate of a target storage device, compressing the inputstream at a compression rate that increases the effective data storagerate of the target storage device and storing the compressed data in thetarget storage device. For instance, assume that a mass storage device(such as a hard disk) has a data storage rate of 20 megabytes persecond. If a storage controller for the mass storage device is capableof compressing an input data stream with an average compression rate of3:1, then data can be stored in the mass storage device at a rate of 60megabytes per second, thereby effectively increasing the storagebandwidth (“storewidth”) of the mass storage device by a factor ofthree. Similarly, accelerated data retrieval comprises retrieving acompressed digital data stream from a target storage device at the rateequal to, e.g., the data access rate of the target storage device andthen decompressing the compressed data at a rate that increases theeffective data access rate of the target storage device. Advantageously,accelerated data storage/retrieval mitigates the traditional bottleneckassociated with, e.g., local and network disk accesses.

Referring now to FIG. 1, a high-level block diagram illustrates a datastorage controller 10 according to one embodiment of the presentinvention. The data storage controller 10 comprises a data compressionengine 12 for compressing/decompressing data (preferably in real-time orpsuedo real-time) stored/retrieved from a hard disk 11 (or any othertype of mass storage device) to provide accelerated datastorage/retrieval. The DCE 12 preferably employs the datacompression/decompression techniques disclosed in U.S. Ser. No.09/210,491 entitled “Content Independent Data Compression Method andSystem,” filed on Dec. 11, 1998, now U.S. Pat. No. 6,195,024, which iscommonly assigned and which is fully incorporated herein by reference.It is to be appreciated that the compression and decompression systemsand methods disclosed in U.S. Pat. No. 6,195,024 are suitable forcompressing and decompressing data at rates, which provide accelerateddata storage and retrieval. A detailed discussion of a preferred“content independent” data compression process will be provided below.

The data storage controller 10 further comprises a cache 13, a diskinterface (or disk controller) 14 and a bus interface 15. The storagecontroller 10 is operatively connected to the hard disk 12 via the diskcontroller 14 and operatively connected to an expansion bus (or mainbus) 16 of a computer system via the bus interface 15. The diskinterface 14 may employ a known disk interface standard such asUltraDMA, SCSI, Serial Storage Architecture, FibreChannel or any otherinterface that provides suitable disk access data rates. In addition,the storage controller 10 preferably utilizes the American NationalStandard for Information Systems (ANSI) AT Attachment Interface(ATA/ATAPI-4) to connect the data storage controller 10 to the hard disk12. As is known in the art, this standard defines the connectors andcables for the physical interconnects between the data storagecontroller and the storage devices, along with the electrical andlogical characteristics of the interconnecting signals.

Further, the bus interface 15 may employ a known standard such as thePCI (Peripheral Component Interconnect) bus interface for interfacingwith a computer system. The use of industry standard interfaces andprotocols is preferable, as it allows the storage controller 10 to bebackwards compatible and seamlessly integrated with current systems.However in new designs the present invention may be utilize any suitablecomputer interface or combination thereof.

It is to be understood that although FIG. 1 illustrates a hard disk 12,the storage controller 10 may be employed with any form of memory deviceincluding all forms of sequential, pseudo-random, and random accessstorage devices. Storage devices as known within the current art includeall forms of random access memory, magnetic and optical tape, magneticand optical disks, along with various other forms of solid-state massstorage devices. The current invention applies to all forms and mannersof memory devices including, but not limited to, storage devicesutilizing magnetic, optical, and chemical techniques, or any combinationthereof. In addition, the cache 13 may comprise volatile or non-volatilememory, or any combination thereof. Preferably, the cache 13 isimplemented in SDRAM (static dynamic random access memory).

The system of FIG. 1 generally operates as follows. When data is readfrom disk by the host computer, data flows from the disk 11 through thedata storage controller 10 to the host computer. Data is stored in oneof several proprietary compression formats on the disk 11 (e.g.,“content independent” data compression). Data blocks are pre-specifiedin length, comprised of single or multiple sectors, and are typicallyhandled in fractional or whole equivalents of tracks, e.g. V2 track,whole track, multiple tracks, etc. To read disk data, a DMA transfer issetup from the disk interface 14 to the onboard cache memory 13. Thedisk interface 14 comprises integral DMA control to allow transfer ofdata from the disk 11 directly to the onboard cache 13 withoutintervention by the DCE 12. It should be noted that the DCE 12 acts as asystem level controller and sets-up specific registers within both thedisk interface 14 and bus interface 15 to facilitate DMA transfers toand from the cache memory 13. To initiate a transfer from the disk 11 tothe cache 13, the DMA transfer is setup via specifying the appropriatecommand (read disk), the source address (disk logical block number),amount of data to be transferred (number of disk logical blocks), anddestination address within the onboard cache memory 13. Then, a diskdata interrupt signal (“DISKINT#”) is cleared (if previously set and notcleared) and the command is initiated by writing to the appropriateaddress space. Once data has been read from disk 11 and placed intoonboard cache memory 13, the DISKINT# interrupt is asserted notifyingthe DCE 12 that requested data is now available in the cache memory 13.Data is then read by the DMA controller within the DCE 12 and placedinto local memory for subsequent decompression. The decompressed data isthen DMA transferred from the local memory of the DCE 12 back to thecache memory 13. Finally, data is DMA transferred via the bus interfacecontroller 15 from the cache memory 13 to the bus 16. It is to beunderstood that in the read mode, the data storage controller acts as abus master. A bus DMA transfer is then setup via specifying theappropriate command (write to host computer), the source address withinthe cache memory 13, the quantity of data words to be transferred(transfers are preferably in 4 byte increments), and the destinationaddress on the host computer. When a bus 16 read or write transactionhas completed, the appropriate interrupt signals (respectively referredto as PCIRDINT# and PCIWRINT#) are asserted to the DCE 12. Either ofthese interrupts are cleared by a corresponding interrupt serviceroutines through a read or write to the appropriate address of the DCE12.

Similarly, when data is written to the disk 11 from the host computer,data flows from the host computer through the data storage controller 10and onto disk 11. Data is normally received from the host computer inuncompressed (raw) format and is compressed by the DCE 12 and stored onthe disk 11. Data blocks from the host are pre-specified in length andare typically handled in blocks that are a fixed multiplier higher thanfractional or whole equivalents of tracks, e.g. V2 track, whole track,multiple tracks, etc. This multiplier is preferably derived from theexpected average compression ratio that is selected when the disk isformatted with the virtual file management system. To read host computerdata, a bus DMA transfer is setup from the host bus 16 to the onboardcache memory 13. The bus interface controller 15 comprises integral DMAcontrol that allows large block transfers from the host computerdirectly to the onboard cache 13 without intervention by the DCE 12. Thebus interface controller 15 acts as a host computer Bus Master whenexecuting such transfer. Once data has been read from the host andplaced into onboard cache memory 13, the data is read by the onboard DMAcontroller (residing on the DCE 12) and placed into local memory forsubsequent compression. The compressed data is then DMA transferred fromthe local memory of the DCE 12 back to the cache memory 13. Finally,data is DMA transferred via the disk controller 14 from the cache 13 tothe disk 11.

As discussed in greater detail below, upon host computer power-up orexternal user reset, the data storage controller 10 initializes theonboard interfaces 14, 15 prior to release of the external host bus 16from reset. The processor of the host computer then requests initialdata from the disk 11 to facilitate the computer's boot-up sequence. Thehost computer requests disk data over the Bus 16 via a command packetissued from the host computer. Command packets are preferably eightwords long (in a preferred embodiment, each word comprises 32 bits).Commands are written from the host computer to the data storagecontroller 10 with the host computer as the Bus Master and the datastorage controller 10 as the slave. The data storage controller 10includes at least one Base Address Register (BAR) for decoding theaddress of a command queue of the data storage controller 10. Thecommand queue resides within the cache 13 or within onboard memory ofthe DCE 12.

When a command is received from the host computer, an interrupt(referred to herein as PCICMDINT#) is generated to the DCE processor.The eight-word command is read by the DCE 12 and placed into the commandqueue. Because the commands occupy a very small amount of memory, thelocation of the command queue is at the discretion of software and theassociated system level performance considerations. Commands may bemoved from the bus interface 16 to the command queue by wither explicitreads and writes by the DCE processor or, as explained below, byutilizing programmed DMA from an Enhanced DMA Controller (EDMA) residingon the DCE 12. This second technique may better facilitate systemthroughput by allowing the EDMA to automatically load commands while thehighly pipelined data compression and decompression processing in theDCE is executed fully undisturbed.

The DCE 12, disk interface 14 and bus interface 15 commonly share thecache 13. As explained in detail below, the storage controller 10preferably provides maximum system bandwidth by allowing simultaneousdata transfers between the disk 12 and cache 13, the DCE 12 and thecache 13, and the expansion bus 16 and the cache 13. This is realized byemploying an integral DMA (direct memory access) protocol that allowsthe DCE 12, disk interface 14 and bus interface 15 to transfer datawithout interrupting or interfering with other ongoing processes. Inparticular, as explained in detail below, an integral bandwidthallocation controller (or arbitrator) is preferably employed to allowthe DCE 12, disk controller 14, and bus interface 15 to access theonboard cache with a bandwidth proportional to the overall bandwidth ofthe respective interface or processing element. The bandwidtharbitration occurs transparently and does not introduce latency inmemory accesses. Bandwidth division is preferably performed with a highdegree of granularity to minimize the size of requisite onboard buffersto synchronize data from the disk interface 14 and bus interface 15.

It is to be appreciated that the implementation of a storage controlleraccording to the present invention significantly accelerates theperformance of a computer system and significantly increases hard diskdata storage capacity. For instance, depending on the compression rate,for personal computers running standard Microsoft Windows® basedbusiness application software, the storage controller provides: (1) anincrease of n:1 in disk storage capacity(for example, assuming acompression ration of 3:1, a 20 gigabyte hard drive effectively becomesa 60 gigabyte hard drive) (2) a significant decrease in the computerboot-up time (turn-on and operating system load) and the time forloading application software and (3) User data storage and retrieval isincreased by a factor of n:1.

Referring now to FIG. 2, a block diagram illustrates a data storagecontroller 20 according to another embodiment of the present invention.More specifically, FIG. 2 illustrates a PCB (printed circuit board)implementation of the data storage controller 10 of FIG. 1. The storagecontroller 20 comprises a DSP (digital signal processor) 21 (or anyother micro-processor device) that implements the DCE 12 of FIG. 1. Thestorage controller 21 further comprises at least one programmable logicdevice 22 (or volatile logic device). The programmable logic device 22preferably implements the logic (program code) for instantiating anddriving both the disk interface 14 and the bus interface 15 and forproviding full DMA capability for the disk and bus interfaces 14, 15.Further, as explained in detail below, upon host computer power-upand/or assertion of a system-level “reset” (e.g., PCI Bus reset), theDSP 21 initializes and programs the programmable logic device 22 beforeof the completion of initialization of the host computer. Thisadvantageously allows the data storage controller 20 to be ready toaccept and process commands from the host computer (via the bus 16) andretrieve boot data from the disk (assuming the data storage controller20 is implemented as the boot device and the hard disk stores the bootdata (e.g., operating system, etc.)).

The data storage controller 20 further comprises a plurality of memorydevices including a RAM (random access memory) device 23 and a ROM (readonly memory) device 24 (or FLASH memory or other types of non-volatilememory). The RAM device 23 is utilized as on-board cache and ispreferably implemented as SDRAM (preferably, 32 megabytes minimum). TheROM device 24 is utilized for non-volatile storage of logic codeassociated with the DSP 21 and configuration data used by the DSP 21 toprogram the programmable logic device 22. The ROM device 24 preferablycomprises a one time (erasable) programmable memory (OTP-EPROM) device.

The DSP 21 is operatively connected to the memory devices 23, 24 and theprogrammable logic device 22 via a local bus 25. The DSP 21 is alsooperatively connected to the programmable logic device 22 via anindependent control bus 26. The programmable logic device 22 providesdata flow control between the DSP 21 and the host computer systemattached to the bus 16, as well as data flow control between the DSP 21and the storage device. A plurality of external I/O ports 27 areincluded for data transmission and/or loading of one programmable logicdevices. Preferably, the disk interface 14 driven by the programmablelogic device 22 supports a plurality of hard drives.

The storage controller 20 further comprises computer reset and power upcircuitry 28 (or “boot configuration circuit”) for controllinginitialization (either cold or warm boots) of the host computer systemand storage controller 20. A preferred boot configuration circuit andpreferred computer initialization systems and protocols are described inU.S. patent application Ser. No. 09/775,897, published as United StatesPatent Application Publication No. 2001-0047473 incorporated herein byreference as well as Section VIII below. Preferably, the bootconfiguration circuit 28 is employed for controlling the initializingand programming the programmable logic device 22 during configuration ofthe host computer system (i.e., while the CPU of the host is held inreset). The boot configuration circuit 28 ensures that the programmablelogic device 22 (and possibly other volatile or partially volatile logicdevices) is initialized and programmed before the bus 16 (such as a PCIbus) is fully reset.

In particular, when power is first applied to the boot configurationcircuit 28, the boot configuration circuit 28 generates a control signalto reset the local system (e.g., storage controller 20) devices such asa DSP, memory, and I/O interfaces. Once the local system is powered-upand reset, the controlling device (such as the DSP 21) will then proceedto automatically determine the system environment and configure thelocal system to work within that environment. By way of example, the DSP21 of the disk storage controller 20 would sense that the data storagecontroller 20 is on a PCI computer bus (expansion bus) and has attachedto it a hard disk on an IDE interface. The DSP 21 would then load theappropriate PCI and IDE interfaces into the programmable logic device 22prior to completion of the host system reset. It is to be appreciatedthat this can be done for all computer busses and boot device interfacesincluding: PCI, NuBus, ISA, Fiber Channel, SCSI, Ethernet, DSL, ADSL,IDE, DMA, Ultra DMA, and SONET. Once the programmable logic device 22 isconfigured for its environment, the boot device controller is reset andready to accept commands over the computer/expansion bus 16. Details ofthe boot process using a boot device comprising a programmable logicdevice will be provided below.

It is to be understood that the data storage controller 20 may beutilized as a controller for transmitting data (compressed oruncompressed) to and from remote locations over the DSP I/O ports 27 orsystem bus 16, for example. Indeed, the I/O ports 27 of the DSP 21 maybe used for transmitting data (compressed or uncompressed) that iseither retrieved from the disk 11 or received from the host system viathe bus 16, to remote locations for processing and/or storage. Indeed,the I/O ports may be operatively connected to other data storagecontrollers or to a network communication channels. Likewise, the datastorage controller 20 may receive data (compressed or uncompressed) overthe I/O ports 27 of the DSP 21 from remote systems that are connected tothe I/O ports 27 of the DSP, for local processing by the data storagecontroller 20. For instance, a remote system may remotely access thedata storage controller (via the I/O ports of the DSP or system bus 16)to utilize the data compression, in which case the data storagecontroller would transmit the compressed data back to the system thatrequested compression.

The DSP 21 may comprise any suitable commercially available DSP orprocessor. Preferably, the data storage controller 20 utilizes a DSPfrom Texas Instruments' 320 series, C62x family, of DSPs (such asTMS320C6211GFN-150), although any other DSP or processor comprising asimilar architecture and providing similar functionalities may beemployed. The preferred DSP is capable of up to 1.2 billion instructionsper second. Additional features of the preferred DSP include a highlyparallel eight processor single cycle instruction execution, onboard 4Kbyte UP Program Cache, 4K L1D Data Cache, and 64K byte Unified L2Program/Data Cache. The preferred DSP further comprises a 32 bitExternal Memory Interface (EMIF) that provides for a glueless interfaceto the RAM 23 and the non-volatile memory 24 (ROM). The DSP furthercomprises two multi-channel channel buffered serial ports (McBSPs) andtwo 32 bit general purpose timers. Preferably, the storage controllerdisables the I/O capability of these devices and utilizes the I/O portsof the DSP as general purpose I/O for both programming the programmablelogic device 22 using a strobed eight bit interface and signaling via aLight Emitting Diode (LED). Ancillary DSP features include a 16 bit HostPort Interface and full JTAG emulation capability for developmentsupport.

The programmable logic device 22 may comprise any form of volatile ornon-volatile memory. Preferably, the programmable logic device 22comprises a dynamically reprogrammable FPGA (field programmable gatearray) such as the commercially available Xilinx Spartan SeriesXCS4OXL-PQ240-5 FPGA. As discussed in detail herein, the FPGAinstantiates and drives the disk and bus interfaces 14, 15.

The non-volatile memory device 24 preferably comprises a 128 KbyteM27W101-80K one time (erasable) programmable read only memory, althoughother suitable non-volatile storage devices may be employed. Thenon-volatile memory device 24 is decoded at a designated memory space inthe DSP 21. The non-volatile memory device 24 stores the logic for theDSP 21 and configuration data for the programmable logic device 22. Morespecifically, in a preferred embodiment, the lower 80 Kbytes of thenonvolatile memory device 24 are utilized for storing DSP program code,wherein the first 1k bytes are utilized for the DSP's boot loader. Uponreset of the DSP 21 (via boot configuration circuit 28), the first 1K ofmemory of the non-volatile memory device 24 is copied into an internalRAM of the DSP 21 by e.g., the DSP's Enhanced DMA Controller (EDMA).Although the boot process begins when the CPU of the host system isreleased from external reset, the transfer of the boot code into the DSPand the DSP's initialization of the programmable logic device actuallyoccurs while the CPU of the host system is held in reset. Aftercompletion of the 1K block transfer, the DSP executes the boot loadercode and continues thereafter with executing the remainder of the codein non-volatile memory device to program the programmable logic device22.

More specifically, in a preferred embodiment, the upper 48K bytes of thenon-volatile memory device 24 are utilized for storing configurationdata associated with the programmable logic device 22. If the datastorage controller 20 is employed as the primary boot storage device forthe host computer, the logic for instantiating and driving the disk andbus interfaces 14, 15 should be stored on the data storage controller 20(although such code may be stored in remotely accessible memorylocations) and loaded prior to release of the host system bus 16 from“reset”. For instance, revision 2.2 of the PCI Local Bus specificationcalls for a typical delay of 100 msec from power-stable before releaseof PCI Reset. In practice this delay is currently 200 msec although thisvaries amongst computer manufacturers. A detailed discussion of thepower-on sequencing and boot operation of the data storage controller 20will be provided below.

FIG. 3 illustrates another embodiment of a data storage controller 35wherein the data storage controller 35 is embedded within themotherboard of the host computer system. This architecture provides thesame functionality as the system of FIG. 2, and also adds the costadvantage of being embedded on the host motherboard. The systemcomprises additional RAM and ROM memory devices 23 a, 24 a, operativelyconnected to the DSP 21 via a local bus 25 a.

FIG. 4 illustrates another embodiment of a data storage controller. Thedata storage controller 40 comprises a PCB implementation that iscapable of supporting RAID levels 0, 1 and 5. This architecture issimilar to those of FIGS. 1 and 2, except that a plurality ofprogrammable logic devices 22, 22 a are utilized. The programmable logicdevice 22 is dedicated to controlling the bus interface 15. Theprogrammable logic device 22 a is dedicated to controlling a pluralityof disk interfaces 14, preferably three interfaces. Each disk interface14 can connect up to two drives. The DSP in conjunction with theprogrammable logic device 22 a can operate at RAID level 0, 1 or 5. AtRAID level 0, which is disk striping, two interfaces are required. Thisis also true for RAID level 1, which is disk minoring. At RAID level 5,all three interfaces are required.

FIG. 5 illustrates another embodiment of a data storage controlleraccording to the present invention. The data storage controller 45provides the same functionality as that of FIG. 4, and has the costadvantage of being embedded within the computer system motherboard.

II. Initializing a Programmable Logic Device

As discussed above with reference to FIG. 2, for example, the datastorage controller 20 preferably employs an onboard Texas InstrumentsTMS320C6211 Digital Signal Processor (DSP) to program the onboard XilinxSpartan Series XCS4OXL FPGA upon power-up or system level PCI reset. Theonboard boot configuration circuit 28 ensures that from system power-upand/or the assertion of a bus reset (e.g., PCI reset), the DSP 21 isallotted a predetermined amount of time (preferably a minimum of 10msec) to boot the DSP 21 and load the programmable logic device 22.Because of a potential race condition between either the host computerpower-up or assertion of PCI Bus reset and configuration of theprogrammable logic device 20 (which is used for controlling the bootdevice and accepting PCI Commands), an “Express Mode” programming modefor configuring the SpartanXL family XCS4OXL device is preferablyemployed. The XCS4OXL is factory set to byte-wide Express-Modeprogramming by setting both the M1/M0 bits of the XCS4OXL to OxO.Further, to accommodate express mode programming of the programmablelogic device 22, the DSP 21 is programmed to utilize its serial portsreconfigured as general purpose I/O. However, after the logic device 22is programmed, the DSP 21 may then reconfigure its serial ports for usewith other devices. Advantageously, using the same DSP ports formultiple purposes affords greater flexibility while minimizing hardwareresources and thus reducing product cost.

The volatile nature of the logic device 22 effectively affords theability to have an unlimited number of hardware interfaces. Any numberof programs for execution by the programmable logic device 22 can bekept in an accessible memory location (EPROM, hard disk, or otherstorage device). Each program can contain new disk interfaces, interfacemodes or subsets thereof. When necessary, the DSP 21 can clear theinterface currently residing in the logic device 22 and reprogram itwith a new interface. This feature allows the data storage controller 20to have compatibility with a large number of interfaces while minimizinghardware resources and thus reducing product cost.

A preferred protocol for programming the programmable logic device canbe summarized in the following steps: (1) Clearing the configurationmemory; (2) Initialization; (3) Configuration; and (4) Start-Up. Wheneither of three events occur: the host computer is first powered-up or apower failure and subsequent recovery occurs (cold boot), or a frontpanel computer reset is initiated (warm boot), the host computer assertsRST# (reset) on the PCI Bus. As noted above, the data storage controller20 preferably comprises a boot configuration circuit 28 that sensesinitial host computer power turn-on and/or assertion of a PCI Bus Reset(“PCI RST#”). It is important to note that assuming the data storagecontroller 20 is utilized in the computer boot-up sequence, it should beavailable exactly 5 clock cycles after the PCI RST# is deasserted, asper PCI Bus Specification Revision 2.2. While exact timings vary fromcomputer to computer, the typical PCI bus reset is asserted forapproximately 200 msec from initial power turn-on.

In general, PCI RST# is asserted as soon as the computer's power exceedsa nominal threshold of about 1 volt (although this varies) and remainsasserted for 200 msec thereafter. Power failure detection of the 5 voltor 3.3 volt bus typically resets the entire computer as if it is aninitial power-up event (i.e., cold boot). Front panel resets (warmboots) are more troublesome and are derived from a debounced push-buttonswitch input. Typical front panel reset times are a minimum of 20 msec,although again the only governing specification limit is 1 msec resetpulse width.

As discussed in detail below, it may not be necessary to reload theprogrammable logic device 22 each time the DSP is reset. The bootconfiguration circuit 20 preferably comprises a state machine outputsignal that is readable by the DSP 21 to ascertain the type of bootprocess requested. For example, with a front-panel reset (warm boot),the power remains stable on the PCI Bus, thus the programmable logicdevice 22 should not require reloading.

Referring now to FIG. 6, a flow diagram illustrates a method forinitializing the programmable logic device 22 according to one aspect ofthe invention. In the following discussion, it is assumed that theprogrammable logic device 22 is always reloaded, regardless of the typeof boot process. Initially, in FIG. 6a , the DSP 21 is reset byasserting a DSP reset signal (step 50). Preferably, the DSP reset signalis generated by the boot circuit configuration circuit 28 (as describedin the above-incorporated U.S. patent application Ser. No. 09/775,897,published as United States Patent Application Publication No.2001-0047473, as well as Section VIII below). While the DSP reset signalis asserted (e.g., active low), the DSP is held in reset and isinitialized to a prescribed state. Upon deassertion of the DSP Resetsignal, the logic code for the DSP (referred to as the “boot loader”) iscopied from the non-volatile logic device 24 into memory residing in theDSP 21 (step 51). This allows the DSP to execute the initialization ofthe programmable logic device 22. In a preferred embodiment, the lower1K bytes of EPROM memory is copied to the first 1k bytes of DSP's lowmemory (0x0000 0000 through Ox0000 03FF). As noted above, the memorymapping of the DSP 21 maps the CE1 memory space located at 0x9000 0000through 0x9001 FFFF with the OTP EPROM. In a preferred embodiment usingthe Texas Instrument DSP TMS320c6211GFN-150, this ROM boot process isexecuted by the EDMA controller of the DSP. It is to be understood,however, that the EDMA controller may be instantiated in theprogrammable logic device (Xilinx), or shared between the DSP andprogrammable logic device.

After the logic is loaded in the DSP 21, the DSP 21 begins execution outof the lower 1K bytes of memory (step 52). In a preferred embodiment,the DSP 21 initializes with at least the functionality to read EPROMMemory (CE 1) space. Then, as described above, the DSP preferablyconfigures its serial ports as general purpose I/O (step 53).

Next, the DSP 21 will initialize the programmable logic device 22 usingone or more suitable control signals. (step 54). After initialization,the DSP 21 begins reading the configuration data of the programmablelogic device 22 from the non-volatile memory 24 (step 55). This processbegins with clearing a Data Byte Counter and then reading the first databyte beginning at a prespecified memory location in the non-volatilememory 24 (step 56). Then, the first output byte is loaded into theDSP's I/O locations with LSB at DO and MSB at D7 (step 57). Before thefirst byte is loaded to the logic device 22, a prespecified time delay(e.g., 5 usec) is provided to ensure that the logic device 22 has beeninitialized (step 58). In particular, this time delay should be of aduration at least equal to the internal setup time of the programmablelogic device 22 from completion of initialization. Once this time delayhas expired, the first data byte in the I/O bus 26 of the DSP 21 islatched into the programmable logic device 22 (step 59).

Next, a determination is made as to whether the Data Byte Counter isless than a prespecified value (step 60). If the Data Byte Counter isless than the prespecified value (affirmative determination in step 60),the next successive data byte for the programmable logic device 22 isread from the non-volatile memory 24 (step 61) and the Data Byte Counteris incremented (step 62).

Next, the read data byte is loaded into the I/O of the DSP (step 63). Atime delay of, e.g., 20 nsec is allowed to expire before the data byteis latched to the programmable logic device to ensure that a minimumdata set-up time to the programmable logic device 21 is observed (step64) and the process is repeated (return to step 60). It is to beappreciated that steps 60-64 may be performed while the current databyte is being latched to the programmable logic device. This provides“pipeline” programming of the logic device 22 and minimizes programmingduration.

When the Data Byte Counter is not less than the prespecified count valuenegative determination in step 60), as shown in FIG. 6b , the last databyte is read from the non-volatile memory and latched to theprogrammable logic device 22, and the DSP 21 will then poll a controlsignal generated by the programmable logic device 22 to ensure that theprogramming of the logic device 22 is successful (step 65). Ifprogramming is complete (affirmative determination in step 66), theprocess continues with the remainder of the data storage controllerinitialization (step 67). Otherwise, a timeout occurs (step 68) and uponexpiration of the timeout, an error signal is provided and theprogramming process is repeated (step 69).

III. Data Storage and Retrieval Protocols

A detailed discussion of operational modes of a data storage controllerwill now be provided with reference to the embodiment of FIG. 2(although it is to be understood that the following discussion isapplicable to all the above-described embodiments). The data storagecontroller 20 utilizes a plurality of commands to implement the datastorage, retrieval, and disk maintenance functions described herein.Each command preferably comprises eight thirty-two bit data words storedand transmitted in little endian format. The commands include: Read DiskData; Write Disk Data; and Copy Disk Data, for example. For example, apreferred format for the “Read Disk Data” command is:

The host computer commands the data storage controller 20 over the PCIBus 16, for example. Upon computer power-up or reset, the host computerissues a PCI Bus Reset with a minimum pulse width of 100 msec (inaccordance with PCI Bus Specification Revision 2.2). Upon completion ofthe PCI Bus reset, the data storage controller 20 is fully initializedand waiting for completion of the PCI configuration cycle. Uponcompletion of the PCI configuration cycles, the data storage controllerwill wait in an idle state for the first disk command.

During operation, the host operating system may issue a command to thedata storage controller 20 to store, retrieve, or copy specific logicaldata blocks. Each command is transmitted over the PCI Bus 16 at theAddress assigned to the Base Address Register (BAR) of the data storagecontroller 20.

The commands issued by the host system to the data storage controllerand the data transmitted to and from the data storage controller arepreferably communicated via a 32 bit, 33 MHz, PCI Data Bus. As notedabove, the PCI Interface is preferably housed within the onboard XilinxSpartan XCS4OXL-5 40,000 field programmable gate array whichinstantiates a PCI 32, 32 Bit, 33 MHz PCI Bus Interface (as per PCI BusRevision 2.2).

The PCI Bus interface operates in Slave Mode when receiving commands andas a Bus Master when reading or writing data. The source and destinationfor all data is specified within each command packet. When setting updata transfers, the Enhanced Direct Memory Access (EDMA) Controller ofthe DSP (or the Xilinx) utilizes two Control Registers, a 16 Word DataWrite to PCI Bus FIFO, a 16 Word Data Read From PCI Bus FIFO, and a PCIData Interrupt (PCIDATINT). The 32 Bit PCI Address Register holds eitherthe starting Source Address for data storage controller Disk Writeswhere data is read from the PCI Bus, or the starting Destination Addressfor data storage controller Disk Reads where data is written to the PCIBus. The second control register is a PCI Count Register that specifiesthe direction of the data transfer along with the number of 32 bit Datawords to be written to or from the PCI bus.

Data is written to the PCI Bus from the DSP via a 16 Word PCI Data WriteFIFO located within a prespecified address range. Data writes from theDSP to anywhere within the address range place that data word in thenext available location within the FIFO. Data is read from the PCI Busto the DSP via a 16 Word PCI Data Read FIFO located within aprespecified address range and data read by the DSP from anywhere withinthis address range provides the next data word from the FIFO.

After completion of the Xilinx initialization by the DSP and subsequentnegation of the PCI Bus Reset signal (RST#) by the host computer's PCIBridge, the data storage controller is ready to accept commands from thehost computer via the PCI Bus. When accepting commands it should benoted that the data storage controller is a PCI Target (Slave) Device.Commands are preferably fixed in length at exactly 8 (thirty-two bit)words long. Commands are written from the host computer to the datastorage controller via the PCI Bus utilizing the data storagecontroller's Base Address Register 0 (BARO). The PCI Bus Reset initiallysets the Command FIFO's Counter to zero and also signals the Xilinx'sPCI Bus State Controller that the Command FIFO is empty and enable toaccept a command.

Whenever a data write occurs within the valid data range of BARO, thedata word is accepted from PCI Bus and placed in the next availablememory position within the Command FIFO. When the last of the 8thirty-two bit data words is accepted by the PCI Bus (thus completingthe command, i.e. last word for the command FIFO to be full), the PCIBus State Controller is automatically set to Target Abort (within samePCI Transaction) or Disconnect Without Data for all subsequent PCItransactions that try to writes to BARO. This automatic setting is theresponsibility of the Xilinx PCI Data Interface.

The PCI Command FIFO State Controller then asserts the Command AvailableInterrupt to the DSP. The DSP services the Command Available Interruptby reading the command data from a prespecified address range. It shouldbe noted that the command FIFO is read sequentially from any data accessthat reads data within such address range. It is the responsibility ofthe DSP to understand that the data is read sequentially from any orderof accesses within the data range and should thus be stored accordingly.

Upon completion of the Command Available Interrupt Service Routine theDSP executes a memory read or write to desired location within the PCIControl Register Space mapped into the DSP's CE3 (Xilinx) memory space.This resets the Command FIFO Counter back to zero. Next, the DSPexecutes a memory read or write to location in the DSP Memory Space thatclears the Command Available Interrupt. Nested interrupts are notpossible since the PCI Bus State Machine is not yet able to accept anyCommand Data at BARO. Once the Command Available Interrupt routine hascleared the interrupt and exited, the DSP may then enable the PCI StateMachine to accept a new command by reading or writing to PCI CommandEnable location within the PCI Command FIFO Control Register Space.

A preferred architecture has been selected to enable the data storagecontroller to operate on one command at a time or to accept multipleprioritized commands in future implementations. Specifically, thedecoupling of the Command Available Interrupt Service Routine from thePCI State Machine that accepts Commands at BARO enables the DSP's“operating system kernel” to accept additional commands at any time bysoftware command. In single command operation, a command is accepted,the Command Available Interrupt Cleared, and the Command executed by thedata storage controller in PCI Master Mode prior to the enabling of thePCI State machine to accept new commands.

In a prioritized multi-command implementation, the “operating systemkernel” may elect to immediately accept new commands or defer theacceptance of new commands based upon any software implemented decisioncriteria. In one embodiment, the 0/S code might only allow apre-specified number of commands to be queued. In another embodiment,commands might only be accepted during processor idle time or when theDSP is not executing time critical (i.e. highly pipelined)compress/decompress routines. In yet another embodiment, variousprocesses are enabled based upon a pre-emptive prioritized basedscheduling system.

As previously stated, the data storage controller retrieves commandsfrom the input command FIFO in 8 thirty-two bit word packets. Prior tocommand interpretation and execution, a command's checksum value iscomputed to verify the integrity of the data command and associatedparameters. If the checksum fails, the host computer is notified of thecommand packet that failed utilizing the Command Protocol Error Handler.Once the checksum is verified the command type and associated parametersare utilized as an offset into the command “pointer” table or nay othersuitable command/data structure that transfers control to theappropriate command execution routine.

Commands are executed by the data storage controller with the datastorage controller acting as a PCI Master. This is in direct contrast tocommand acceptance where the data storage controller acts as a PCISlave. When acting as a PCI Bus Master, the data storage controllerreads or writes data to the PCI Bus utilizing a separate PCI Bus DataFIFO (distinct & apart from the Command FIFO). The PCI Data FIFO is 64(thirty-two bit) words deep and may be utilized for either data reads ordata writes from the DSP to the PCI Bus, but not both simultaneously.

For data to be written from the data storage controller to the HostComputer, the DSP must first write the output data to the PCI Bus DataFIFO. The Data FIFO is commanded to PCI Bus Data Write Mode by writingto a desired location within the Xilinx (CE3) PCI Control RegisterSpace. Upon PCI Bus Reset the default state for the PCI Data FIFO iswrite mode and the PCI Data FIFO Available Interrupt is cleared. The PCIData FIFO Available Interrupt should also be software cleared by writingto a prespecified location. Preferably, the first task for the datastorage controller is for system boot-up or application code to bedownloaded from disk. For reference, PCI Data Read Mode is commanded bywriting to location BFFO 0104. The PCI Bus Reset initializes the DataFIFO Pointer to the first data of the 64 data words within the FIFO.However this pointer should always be explicitly initialized by a memorywrite to location BFFO 0108. This ensures that the first data wordwritten to the FIFO by the DSP performing the data write anywhere inaddress range B000 0000 to B000 01FF is placed at the beginning of theFIFO. Each subsequent write to any location within this address rangethen places one thirty-two bit data word into the next availablelocation within the PCI Data FIFO. The FIFO accepts up to 64 thirty-twobit data words although it should be clearly understood that not alldata transfers to and from the PCI Bus will consist of a full FIFO.Counting the number of thirty-two bit data words written to the PCI DataFIFO is the responsibility of the DSP Code. It is envisioned that theDSP will, in general, use 64 word DMA data transfers, thus alleviatingany additional processor overhead.

When the data has been transferred from the DSP to the PCI Data FIFO,the PCI Bus Controller also needs the address of the PCI Target alongwith the number of data words to be transmitted. In the current datastorage controller implementation, the PCI Bus Address is thirty-twobits wide, although future PCI bus implementations may utilize multiwordaddressing and/or significantly larger (64 bit & up) address widths. Thesingle thirty-two bit address word is written by the DSP to memorylocation aaaa+0x10 in the PCI Control Register Space.

Finally, the PCI Bus Data Write transaction is initiated by writing thePCI Data FIFO word count to a prespecified memory address. The wordcount value is always decimal 64 or less (0x3F). When the count registeris written the value is automatically transferred to the PCI Controllerfor executing the PCI Bus Master writes.

When the PCI Bus has completed the transfer of all data words within thePCI Data FIFO the PCI Data FIFO Available Interrupt is set. The DSP PCIData FIFO Available Interrupt handler will then check to see ifadditional data is waiting or expected to be written to the PCI DataBus. If additional data is required the interrupt is cleared and thedata transfer process repeats. If no additional data is required to betransferred then the interrupt is cleared and the routine must exit to asystem state controller. For example, if the command is complete thenmaster mode must be disabled and then slave mode (command mode)enabled—assuming a single command by command execution data storagecontroller.

For data to be read by the data storage controller from the HostComputer, the DSP must command the PCI Bus with the address and quantityof data to be received.

The PCI Data FIFO is commanded to PCI Bus Data Read Mode by writing to adesired location within the Xilinx (CE3) PCI Control Register Space.Upon PCI Bus Reset the default state for the PCI Data FIFO is Write Modeand the PCI Data FIFO Full Interrupt is cleared. The PCI Data FIFO FullInterrupt should also be cleared via software by writing to suchlocation. The PCI Bus Reset also initializes the PCI Data FIFO Pointerto the first data word of the available 64 data words within the FIFO.However this pointer should always be explicitly initialized by a memorywrite to prespecified location.

For data to be read from the PCI Bus by the data storage controller, theXilinx PCI Bus Controller requires the address of the PCI Target alongwith the number of data words to be received. In the current datastorage controller implementation, the PCI Bus Address is thirty-twobits wide, although future PCI bus implementations may utilize multiwordaddressing and/or significantly larger (64 bit & up) address widths. Thesingle thirty-two bit address word is written by the DSP to prespecifiedmemory location in the PCI Control Register Space.

Finally, the PCI Bus Data Read transaction is initiated by writing thePCI Data FIFO word count to prespecified memory address. The word countvalue is always decimal 64 or less (0x3F). When the count register iswritten the value is automatically transferred to the PCI Controller forexecuting the PCI Bus Master Read.

When the PCI Bus has received all the requested data words PCI Data FIFOFull

Interrupt is set. The DSP PCI Data FIFO Full Interrupt handler will thencheck to see if additional data is waiting or expected to be read fromthe PCI Data Bus. If additional data is required the interrupt iscleared and the data receipt process repeats. If no additional data isrequired to be transferred, then the interrupt is cleared and theroutine exits to a system state controller. For example, if the commandis complete then master mode must be disabled and then slave mode(command mode) enabled—assuming a single command by command executiondata storage controller.

It is clearly understood that there are other techniques for handlingthe PCI Data transfers. The current methodology has been selected tominimize the complexity and resource utilization of the Xilinx GateArray. It should also be understood that the utilization of asynchronousmemory reads and writes to initialize system states and synchronizeevents at a software level aids in both hardware and system level debugat the expense of increase software overhead. Subsequent embodiments ofthe gate array may automate resource intensive tasks if system levelperformance mandates.

IV. Memory Bandwidth Allocation

The onboard cache of the data storage controller is shared by the DSP,Disk Interface, and PCI Bus. The best case, maximum bandwidth for theSDRAM memory is 70 megawords per second, or equivalently, 280 megabytesper second. The 32 bit PCI Bus interface has a best case bandwidth of132 megabytes per second, or equivalently 33 megawords per second. Incurrent practice, this bandwidth is only achieved in short bursts. Thegranularity of PCI data bursts to/from the data storage controller isgoverned by the PCI Bus interface data buffer depth of sixteen words (64bytes). The time division multiplexing nature of the current PCI DataTransfer Buffering methodology cuts the sustained PCI bandwidth down to66 megabytes/second.

Data is transferred across the ultraDMA disk interface at a maximumburst rate of 66 megabytes/second. It should be noted that the burstrate is only achieved with disks that contain onboard cache memory.Currently this is becoming more and more popular within the industry.However assuming a disk cache miss, the maximum transfer rates fromcurrent disk drives is approximately six megabytes per second. Allottingfor technology improvements over time, the data storage controller hasbeen designed for a maximum sustained disk data rate of 20 megabytessecond (5 megawords/second). A design challenge is created by the needfor continuous access to the SDRAM memory. Disks are physical devicesand it is necessary to continuously read data from disk and place itinto memory, otherwise the disk will incur a full rotational latencyprior to continuing the read transaction. The maximum SDRAM accesslatency that can be incurred is the depth of the each of the two diskFIFO s or sixteen data. Assuming the FIFO is sixteen words deep themaximum latency time for emptying the other disk FIFO and restoring itto the disk interface is sixteen words at 5 megawords per second or(16×3.2 usec)=1 usec. Each EMIF clock cycle is 14.2857 nsec, thus themaximum latency translates to 224 clock cycles. It should be noted thattransfers across the disk interface are 16 bits wide, thus the FPGA isrequired to translate 32 bit memory transfers to 16 bit disk transfers,and vice-versa.

The DSP services request for its external bus from two requestors, theEnhanced Direct Memory Access (EDMA) Controller and an external sharedmemory device controller. The DSP can typically utilize the full 280megabytes of bus bandwidth on an 8k through 64 K byte (2k word through16k word) burst basis. It should be noted that the Data Storage andRetreival Application (DSRA) does not utilize the SDRAM memory forinterim processing storage, and as such only utilizes bandwidth indirect proportion to disk read and write commands.

For a single read from disk transaction data is transferred from and DMAtransfer into SDRAM memory. This data is then DMA transferred by the DSPinto onboard DSP memory, processed, and re transferred back to SDRAM indecompressed format (3 words for every one word in). Finally the data isread from SDRAM by the PCI Bus Controller and placed into host computermemory. This equates to eight SDRAM accesses, one write from disk, oneread by the DSP, three writes by the DSP and three by the PCI Bus. Diskwrite transactions similarly require eight SDRAM accesses, three fromthe PCI, three DSP reads, one DSP write, and one to the disk.

Neglecting overhead for setting up DMA transfers, arbitration latencies,and memory wait states for setting up SDRAM transactions, the maximumDSRA theoretical SDRAM bandwidth limit for disk reads or writes is 280/8megabytes second or 35 megabytes second. It should be noted that thebest case allocation of SDRAM bandwidth would be dynamic dependent uponthe data compression and decompression ratios. Future enhancements tothe data storage controller will utilize a programmable timeslice systemto allocate SDRAM bandwidth, however this first embodiment will utilizea fixed allocation ratio as follows:

If all three requestors require SDRAM simultaneously:

PCI Bus Interface 3/8 DSP Accesses 4/8 UltraDMA Disk Interface 1/8

If only the PCI Bus and DSP require SDRAM:

PCI Bus Interface 4/8 DSP Accesses 4/8

If only the DSP and Disk require SDRAM:

DSP Accesses 6/8 UltraDMA Disk Interface 2/8

If only the PCI Bus and Disk require SDRAM:

PCI Bus Interface 6/8 UltraDMA Disk Interface 2/8

If only one device requires SDRAM it receives the full SDRAM bandwidth.It should be noted that different ratios may be applied based upon theanticipated or actual compression and/or decompression ratios. Forexample in the case of all three requestors active the followingequation applies. Assume that data storage accelerator achieves acompression ratio A:B for example 3:1. The Numerator and denominators ofthe various allocations are defined as follows:

PCI Bus Interface A/K DSP Accesses (A + B)/K UltraDMA Disk Interface B/K

Where Further define a sum K equal to the sum of the numerators of thePCI Bus interface fraction, the DSP Access fraction, and the UltraDMADisk Interfaces, i.e. K=2(A+B). Similarly:

If only the PCI Bus and DSP require SDRAM:

PCI Bus Interface (A + B)/K DSP Accesses (A + B)/K

If only the DSP and Disk require SDRAM:

DSP Accesses 2A/K UltraDMA Disk Interface 2B/K

If only the PCI Bus and Disk require SDRAM:

PCI Bus Interface 2A/K UltraDMA Disk Interface 2B/K

It should be noted that the resultant ratios may all be scaled by aconstant in order to most effectively utilize the bandwidths of theinternal busses and external interfaces. In addition each ratio can bescale by an adjustment factor based upon the time required to completeindividual cycles. For example if PCI Bus interface takes 20% longerthan all other cycles, the PCI time slice should be adjusted longeraccordingly.

V. Instant Boot Device For Operating System, Application Program andLoading

Typically, with conventional boot device controllers, after reset, theboot device controller will wait for a command over the computer bus(such as PCI). Since the boot device controller will typically be resetprior to bus reset and before the computer bus starts sending commands,this wait period is unproductive time. The initial bus commandsinevitably instruct the boot device controller to retrieve data from theboot device (such as a disk) for the operating system. Since most bootdevices are relatively slow compared to the speed of most computerbusses, a long delay is seen by the computer user. This is evident inthe time it takes for a typical computer to boot.

It is to be appreciated that a data storage controller (having anarchitecture as described herein) may employ a technique of datapreloading to decrease the computer system boot time. Upon host systempower-up or reset, the data storage controller will perform aself-diagnostic and program the programmable logic device (as discussedabove) prior to completion of the host system reset (e.g., PCI busreset) so that the logic device can accept PCI Bus commands after systemreset. Further, prior to host system reset, the data storage controllercan proceed to pre-load the portions of the computer operating systemfrom the boot device (e.g., hard disk) into the on-board cache memory.The data storage controller preloads the needed sectors of data in theorder in which they will be needed. Since the same portions of theoperating system must be loaded upon each boot process, it isadvantageous for the boot device controller to preload such portions andnot wait until it is commanded to load the operating system. Preferably,the data storage controller employs a dedicated JO channel of the DSP(with or without data compression) to pre-load computer operatingsystems and applications.

Once the data is preloaded, when the computer system bus issues itsfirst read commands to the data storage controller seeking operatingsystem data, the data will already be available in the cache memory ofthe data storage controller. The data storage controller will then beable to instantly start transmitting the data to the system bus. Beforetransmission to the bus, if the data was stored in compressed format onthe boot device, the data will be decompressed. The process ofpreloading required (compressed) portions of the operating systemsignificantly reduces the computer boot process time.

In addition to preloading operating system data, the data storagecontroller could also preload other data that the user would likely wantto use at startup. An example of this would be a frequently usedapplication such as a word processor and any number of document files.

There are several techniques that may be employed in accordance with thepresent invention that would allow the data storage controller to knowwhat data to preload from the boot device. One technique utilizes acustom utility program that would allow the user to specify whatapplications/data should be preloaded.

Another technique (illustrated by the flow diagram of FIGS. 7a and 7b )that may be employed comprises an automatic process that requires noinput from the user. With this technique, the data storage controllermaintain a list comprising the data associated with the first series ofdata requests received by the data storage controller by the host systemafter a power-on/reset. In particular, referring to FIG. 7a , during thecomputer boot process, the data storage controller will receive requestsfor the boot data (step 70). In response, the data storage controllerwill retrieve the requested boot data from the boot device (e.g., harddisk) in the local cache memory (step 71). For each requested datablock, the data storage controller will record the requested data blocknumber in a list (step 72). The data storage controller will record thedata block number of each data block requested by the host computerduring the boot process (repeat steps 70-72). When the boot process iscomplete (affirmative determination in step 73), the data storagecontroller will store the data list on the boot device (or other storagedevice) (step 74).

Then, upon each subsequent power-on/reset (affirmative result in step75), the data storage controller would retrieve and read the stored list(step 76) and proceed to preload the boot data specified on the list(i.e., the data associated with the expected data requests) into theonboard cache memory (step 77). It is to be understood that thedepending on the resources of the given system (e.g., memory, etc.), thepreloading process may be completed prior to commencement of the bootprocess, or continued after the boot process begins (in which casebooting and preloading are performed simultaneously).

When the boot process begins (step 78) (i.e., the storage controller isinitialized and the system bus reset is deasserted), the data storagecontroller will receive requests for boot data (step 79). If the hostcomputer issues a request for boot data that is pre-loaded in the localmemory of the data storage controller (affirmative result in step 80),the request is immediately serviced using the preloaded boot data (step81). If the host computer issues a request for boot data that is notpreloaded in the local memory of the data storage controller (negativedetermination in step 80), the controller will retrieve the requesteddata from the boot device, store the data in the local memory, and thendeliver the requested boot data to the computer bus (step 82). Inaddition, the data storage controller would update the boot data list byrecording any changes in the actual data requests as compared to theexpected data requests already stored in the list (step 83). Then, uponthe next boot sequence, the boot device controller would pre-load thatdata into the local cache memory along with the other boot datapreviously on the list.

Further, during the boot process, if no request is made by the hostcomputer for a data block that was pre-loaded into the local memory ofthe data storage controller (affirmative result in step 84), then theboot data list will be updated by removing the non-requested data blockfrom the list (step 85). Thereafter, upon the next boot sequence, thedata storage controller will not pre-load that data into local memory.

VI. Quick Launch for Operating System, Application Program, and Loading

It is to be appreciated that the data storage controller (having anarchitecture as described herein) may employ a technique of datapreloading to decrease the time to load application programs (referredto as “quick launch”). Conventionally, when a user launches anapplication, the file system reads the first few blocks of the file offthe disk, and then the portion of the loaded software will request viathe file system what additional data it needs from the disk. Forexample, a user may open a spreadsheet program, and the program may beconfigured to always load a company spreadsheet each time the program isstarted. In addition, the company spreadsheet may require data fromother spreadsheet files.

In accordance with the present invention, the data storage controllermay be configured to “remember” what data is typically loaded followingthe launch of the spreadsheet program, for example. The data storagecontroller may then proceed to preload the company spreadsheet and allthe necessary data in the order is which such data is needed. Once thisis accomplished, the data storage controller can service read commandsusing the preloaded data. Before transmission to the bus, if thepreloaded data was stored in compressed format, the data will bedecompressed. The process of preloading (compressed) program datasignificantly reduces the time for launching an application.

Preferably, a custom utility program is employed that would allow theuser to specify what applications should be made ready for quick launch.

FIGS. 8a and 8b comprise a flow diagram of a quick launch methodaccording to one aspect of the present invention. With this technique,the data storage controller maintains a list comprising the dataassociated with launching an application. In particular, when anapplication is first launched, the data storage controller will receiverequests for the application data (step 90). In response, the datastorage controller will retrieve the requested application data frommemory (e.g., hard disk) and store it in the local cache memory (step91). The data storage controller will record the data block number ofeach data block requested by the host computer during the launch process(step 92). When the launch process is complete (affirmativedetermination in step 93), the data storage controller will store thedata list in a designated memory location (step 94).

Then, referring to FIG. 8b , upon each subsequent launch of theapplication (affirmative result in step 95), the data storage controllerwould retrieve and read the stored list (step 96) and then proceed topreload the application data specified on the list (i.e., the dataassociated with the expected data requests) into the onboard cachememory (step 97). During the application launch process, the datastorage controller will receive requests for application data (step 98).If the host computer issues a request for application data that ispre-loaded in the local memory of the data storage controller(affirmative result in step 99), the request is immediately servicedusing the preloaded data (step 100). If the host computer issues arequest for application data that is not preloaded in the local memoryof the data storage controller (negative result in step 99), thecontroller will retrieve the requested data from the hard disk memory,store the data in the local memory, and then deliver the requestedapplication data to the computer bus (step 101). In addition, the datastorage controller would update the application data list by recordingany changes in the actual data requests as compared to the expected datarequests already stored in the list (step 102).

Further, during the launch process, if no request is made by the hostcomputer for a data block that was pre-loaded into the local memory ofthe data storage controller (affirmative result in step 103), then theapplication data list will be updated by removing the non-requested datablock from the list (step 104). Thereafter, upon the next launchsequence for the given application, the data storage controller will notpre-load that data into local memory.

It is to be understood that the quick boot and quick launch methodsdescribed above are preferably implemented by a storage controlleraccording to the present invention and may or may not utilize datacompression/decompression by the DSP. However, it is to be understoodthat the quick boot and quick launch methods may be implemented by aseparate device, processor, or system, or implemented in software.

VII. Content Independent Data Compression

It is to be understood that any conventional compression/decompressionsystem and method (which comply with the above mentioned constraints)may be employed in the data storage controller for providing accelerateddata storage and retrieval in accordance with the present invention.Preferably, the present invention employs the datacompression/decompression techniques disclosed in the above-incorporatedU.S. Pat. No. 6,195,024.

Referring to FIG. 9, a detailed block diagram illustrates an exemplarydata compression system 110 that may be employed herein. Details of thisdata compression system are provided in U.S. Pat. No. 6,195,024. In thisembodiment, the data compression system 110 accepts data blocks from aninput data stream and stores the input data block in an input buffer orcache 115. It is to be understood that the system processes the inputdata stream in data blocks that may range in size from individual bitsthrough complete files or collections of multiple files. Additionally,the input data block size may be fixed or variable. A counter 120 countsor otherwise enumerates the size of input data block in any convenientunits including bits, bytes, words, and double words. It should be notedthat the input buffer 115 and counter 120 are not required elements ofthe present invention. The input data buffer 115 may be provided forbuffering the input data stream in order to output an uncompressed datastream in the event that, as discussed in further detail below, everyencoder fails to achieve a level of compression that exceeds an a priorispecified minimum compression ratio threshold.

Data compression is performed by an encoder module 125 which maycomprise a set of encoders E1, E2, E3 . . . En. The encoder set E1, E2,E3 . . . En may include any number “n” (where n may =1) of thoselossless encoding techniques currently well known within the art such asrun length, Huffman, Lempel-Ziv Dictionary Compression, arithmeticcoding, data compaction, and data null suppression. It is to beunderstood that the encoding techniques are selected based upon theirability to effectively encode different types of input data. It is to beappreciated that a full complement of encoders are preferably selectedto provide a broad coverage of existing and future data types.

The encoder module 125 successively receives as input each of thebuffered input data blocks (or unbuffered input data blocks from thecounter module 120). Data compression is performed by the encoder module125 wherein each of the encoders E1 . . . En processes a given inputdata block and outputs a corresponding set of encoded data blocks. It isto be appreciated that the system affords a user the option toenable/disable any one or more of the encoders E1 . . . En prior tooperation. As is understood by those skilled in the art, such featureallows the user to tailor the operation of the data compression systemfor specific applications. It is to be further appreciated that theencoding process may be performed either in parallel or sequentially. Inparticular, the encoders E1 through En of encoder module 125 may operatein parallel (i.e., simultaneously processing a given input data block byutilizing task multiplexing on a single central processor, via dedicatedhardware, by executing on a plurality of processor or dedicated hardwaresystems, or any combination thereof). In addition, encoders E1 throughEn may operate sequentially on a given unbuffered or buffered input datablock. This process is intended to eliminate the complexity andadditional processing overhead associated with multiplexing concurrentencoding techniques on a single central processor and/or dedicatedhardware, set of central processors and/or dedicated hardware, or anyachievable combination. It is to be further appreciated that encoders ofthe identical type may be applied in parallel to enhance encoding speed.For instance, encoder E1 may comprise two parallel Huffman encoders forparallel processing of an input data block.

A buffer/counter module 130 is operatively connected to the encodermodule 125 for buffering and counting the size of each of the encodeddata blocks output from encoder module 125. Specifically, thebuffer/counter 130 comprises a plurality of buffer/counters BC1, BC2,BC3 . . . BCn, each operatively associated with a corresponding one ofthe encoders E1 . . . En. A compression ratio module 135, operativelyconnected to the output buffer/counter 130, determines the compressionratio obtained for each of the enabled encoders E1 . . . En by takingthe ratio of the size of the input data block to the size of the outputdata block stored in the corresponding buffer/counters BC1 BCn. Inaddition, the compression ratio module 135 compares each compressionratio with an a priori-specified compression ratio threshold limit todetermine if at least one of the encoded data blocks output from theenabled encoders E1 . . . En achieves a compression that exceeds an apriori-specified threshold. As is understood by those skilled in theart, the threshold limit may be specified as any value inclusive of dataexpansion, no data compression or expansion, or any arbitrarily desiredcompression limit. A description module 138, operatively coupled to thecompression ratio module 135, appends a corresponding compression typedescriptor to each encoded data block which is selected for output so asto indicate the type of compression format of the encoded data block. Adata compression type descriptor is defined as any recognizable datatoken or descriptor that indicates which data encoding technique hasbeen applied to the data. It is to be understood that, since encoders ofthe identical type may be applied in parallel to enhance encoding speed(as discussed above), the data compression type descriptor identifiesthe corresponding encoding technique applied to the encoded data block,not necessarily the specific encoder. The encoded data block having thegreatest compression ratio along with its corresponding data compressiontype descriptor is then output for subsequent data processing, storage,or transmittal. If there are no encoded data blocks having a compressionratio that exceeds the compression ratio threshold limit, then theoriginal unencoded input data block is selected for output and a nulldata compression type descriptor is appended thereto. A null datacompression type descriptor is defined as any recognizable data token ordescriptor that indicates no data encoding has been applied to the inputdata block. Accordingly, the unencoded input data block with itscorresponding null data compression type descriptor is then output forsubsequent data processing, storage, or transmittal.

Again, it is to be understood that the embodiment of the datacompression engine of FIG. 9 is exemplary of a preferred compressionsystem which may be implemented in the present invention, and that othercompression systems and methods known to those skilled in the art may beemployed for providing accelerated data storage in accordance with theteachings herein. Indeed, in another embodiment of the compressionsystem disclosed in the above-incorporated U.S. Pat. No. 6,195,024, atimer is included to measure the time elapsed during the encodingprocess against an a priori-specified time limit. When the time limitexpires, only the data output from those encoders (in the encoder module125) that have completed the present encoding cycle are compared todetermine the encoded data with the highest compression ratio. The timelimit ensures that the real-time or pseudo real-time nature of the dataencoding is preserved. In addition, the results from each encoder in theencoder module 125 may be buffered to allow additional encoders to besequentially applied to the output of the previous encoder, yielding amore optimal lossless data compression ratio. Such techniques arediscussed in greater detail in the above-incorporated U.S. Pat. No.6,195,024.

Referring now to FIG. 10, a detailed block diagram illustrates anexemplary decompression system that may be employed herein oraccelerated data retrieval as disclosed in the above-incorporated U.S.Pat. No. 6,195,024. In this embodiment, the data compression engine 180retrieves or otherwise accepts compressed data blocks from one or moredata storage devices and inputs the data via a data storage interface.It is to be understood that the system processes the input data streamin data blocks that may range in size from individual bits throughcomplete files or collections of multiple files. Additionally, the inputdata block size may be fixed or variable.

The data decompression engine 180 comprises an input buffer 155 thatreceives as input an uncompressed or compressed data stream comprisingone or more data blocks. The data blocks may range in size fromindividual bits through complete files or collections of multiple files.Additionally, the data block size may be fixed or variable. The inputdata buffer 55 is preferably included (not required) to provide storageof input data for various hardware implementations. A descriptorextraction module 160 receives the buffered (or unbuffered) input datablock and then parses, lexically, syntactically, or otherwise analyzesthe input data block using methods known by those skilled in the art toextract the data compression type descriptor associated with the datablock. The data compression type descriptor may possess valuescorresponding to null (no encoding applied), a single applied encodingtechnique, or multiple encoding techniques applied in a specific orrandom order (in accordance with the data compression system embodimentsand methods discussed above).

A decoder module 165 includes one or more decoders D1 . . . Dn fordecoding the input data block using a decoder, set of decoders, or asequential set of decoders corresponding to the extracted compressiontype descriptor. The decoders D1 . . . Dn may include those losslessencoding techniques currently well known within the art, including: runlength, Huffman, Lempel-Ziv Dictionary Compression, arithmetic coding,data compaction, and data null suppression. Decoding techniques areselected based upon their ability to effectively decode the variousdifferent types of encoded input data generated by the data compressionsystems described above or originating from any other desired source.

As with the data compression systems discussed in U.S. Pat. No.6,195,024, the decoder module 165 may include multiple decoders of thesame type applied in parallel so as to reduce the data decoding time. Anoutput data buffer or cache 170 may be included for buffering thedecoded data block output from the decoder module 165. The output buffer170 then provides data to the output data stream. It is to beappreciated by those skilled in the art that the data compression system180 may also include an input data counter and output data counteroperatively coupled to the input and output, respectively, of thedecoder module 165. In this manner, the compressed and correspondingdecompressed data block may be counted to ensure that sufficientdecompression is obtained for the input data block.

Again, it is to be understood that the embodiment of the datadecompression system 180 of FIG. 10 is exemplary of a preferreddecompression system and method which may be implemented in the presentinvention, and that other data decompression systems and methods knownto those skilled in the art may be employed for providing accelerateddata retrieval in accordance with the teachings herein.

VIII. Boot Configuration Circuit and Computer Initialization Systems andProtocols

FIG. 11 illustrates a high-level block diagram of a boot managementcircuit 1100 according to an embodiment of the present invention. Ingeneral, a preferred architecture of the boot management circuit 1100comprises a component for sensing power-up and user/system commandedreset requests and a component for generating control signals inresponse to such power-up and commanded requests for causing logic codeto be loaded into one or more programmable logic devices in advance ofuse of such programmable logic devices in a boot process. Furthermore, apreferred boot management circuit comprises a component for determiningthe type of boot process that was initiated (e.g., power-up or commandedreset) and providing an indication of such boot process.

The exemplary boot management circuit 1100 of FIG. 11 comprises aplurality of inputs for receiving a power-supply-monitoring signal 1102,an optional system-coldboot-reset-request signal 1104, an optionalcommanded-warm-boot-reset-request signal 1106, (optionally) a legacysystem-reset signal 1108/1110; and optionally anexpansionbus-reset-signal 1112.

In future system implementations (i.e. non-legacy) utilizing the presentinvention, a preferred implementation is to employ either thepower-supply-monitoring signal 1102 and/or thesystem-cold-boot-reset-request signal 1104 for determining cold bootrequests. Similarly the commanded-warm-boot-reset-request signal 1106 isutilized to sense warm boot requests.

In existing (i.e., legacy) computer architectures, signals such as thesystem-coldboot-reset-request signal 1104 and thecommanded-warm-boot-reset-request signal 1106 are typically notavailable from the current hardware/software implementation, thus onlyexistent signals must be utilized that are generated by the computer orexpansion bus. Hence, preferably, for implementations within a legacysystem, the power-supply-monitoring signal 1102 coupled to either thepower supply or the expansion bus power is utilized in conjunction witheither the expansionbus-bus-reset signal 1112 or the system-reset signal1108/1110 to distinguish between a cold and warm boot. It should benoted that in legacy systems, the expansionbus-bus-reset signal 1112 istypically derived from the system-reset signal 1108/1110, usually withappropriate buffering or some other form of signal conditioning. Thus,when the boot management circuit 1100 is implemented in a legacy system,the system-reset signal 1108/1110 or expansionbus-bus-reset signal 1112is preferably monitored along with power-supply-monitoring signal 1102.If the system-reset signal 1108/1110 or the expansionbus-bus-resetsignal 1112 is asserted and the power-supply-monitoring signal 1102 isabove the specified threshold (deemed power supply valid), then the bootprocess is a warm boot. However, if the system-reset signal 1108/1110 orthe expansionbus-bus-reset signal 1112 is asserted and thepower-supply-monitoring signal 1102 is below the specified threshold(deemed power supply invalid), then the boot process is a cold boot.

The exemplary boot management circuit 1100 further comprises a pluralityof output pins for outputting a boot-device-reset signal 1114, asystem-reset signal 1108/1110 (depending if a cold or warm boot processis initiated), and (optionally) indicator signals such as awarm-boot-flag indicator 1116 and/or a cold-boot-flag indicator 1118.

For non-legacy systems, it may be advantageous to generate the optionalsystem-reset signal 1108/1110 signal from the logical OR of thesystem-cold-boot-reset-request signal 1104 and thecommanded-warm-boot-reset-request signal 1106 to minimize logiccircuitry. In the case of non-legacy systems the system-reset 1108/1110is not an input to the boot management circuit 1100 but is an outputgenerated by the boot management circuit 1100. The non-legacy use of thesystem-reset 1108/1110 is similar to its use in legacy systems where thesignal 1108/1110 may be utilized to reset processors, peripherals, andall other non-volatile elements of the boot device. For non-legacysystems the warm-boot-flag signal 1050 and the cold-boot-flag signal1040 may be derived from their respective input request signals 1104 and1106. For legacy systems the previously specified logic is preferablyapplied. It is to be appreciated that the boot management circuit 1100according to the present invention can be readily employed in allexisting and future platform architectures. As such, it is to be furtherunderstood that the input signals 1102, 1104, 1106, 1108/1110, 1112 andoutput signals 1114, 1108/1110, 1116, and 1118 are labeled with namesthat describe their associated functions, and that, depending on theplatform, system or application, other signals providing correspondingfunctions of the signals depicted in FIG. 11 may be applied.

It is to be further appreciated that the boot-device-reset signal 1114provides a mechanism for initiating the loading of the programmablelogic device in advance of the use of the programmable logic device inthe boot process. The cold-boot-flag indicator 1118 and thewarm-boot-flag indicator 1116 indicate which type boot process has beencommanded. Advantageously, the output flags 1116 and 1118 provide anindication that allows additional logic that is implemented in eitherhardware, software, or any combination thereof, to elect to either loador reload program code in the programmable logic device, or leave intactthe current programming of the programmable logic device.

Indeed, depending on the application, it may or may not be advantageousto reload the programmable logic devices. The system-reset output1108/1110, typically resets either all or a portion of the PCcomponents, appliance components, or system components. It should benoted that while singular input signals are shown, the input signals areindicative of a signal type and may each occur in pluralities. Forexample, the power-supply-monitoring signal 1102 may comprise aplurality of power senses. Typically, the individual senses that may beutilized include +5 volts, +3.3 volts, +1.8 volts, +1.5 volts, +12volts, and −12 volts, although any suitable voltage or combinationthereof may be implemented. The power-supply-monitoring signal 1102 maybe monitored and logically combined using any suitable conventionallogic equation to provide a power sense. Certain power supply voltagesare used for specific functions. For example +5 and +3.3 volts may beutilized for logic input and output while lower voltages such as +1.5volts may be utilized for internal logic cores of high-density logicdevices and processors. The process of monitoring voltages isapplication specific to a number of parameters including the specificlogic implementation, system functionality, and/or processors utilizedin the computer or appliance. Further, the ordering may be sensed toensure that the power has been applied in the proper sequence, i.e., thelogic cores are powered before I/O devices to avoid latch up).

Referring now to FIG. 12, a plurality of timing diagrams are showndepicting both cold and warm boot process for implementation of the bootmanagement circuit 1100 in a legacy system. In FIG. 12(a), upon power-upof the system, a power-supply-monitoring signal 1102 reaches a stableand acceptable voltage operating range 1202 within a given time period.The phase lag associated with the power-supply-monitoring signal 1102may vary based upon factors such as the source impedance and loadcondition of the input source and the internal functioning of the powersupply, topology, analog or switching, frequency of switching, capacity,etc. Then, as illustrated in FIG. 12(b), the system-reset signal 1108for a cold boot is generated, which typically approximates thepower-supply-monitoring signal 1102 until a minimum threshold voltage1204 is reached so as to enable proper logic operation. Once the minimumthreshold voltage 1204 is reached, (with a cold boot process), thesystem-reset signal 1108 is asserted for X milliseconds. Although thetime period X is typically 200 milliseconds, any suitable value for Xmay be implemented in the present invention, as the present invention isnot specific to any given value. Indeed, it is anticipated that thistime period with grow smaller in future systems. Additionally, it is notrequired that the system-reset signal 1108 follow thepower-supply-monitoring signal 1102. Indeed, the system-reset signal 410may remain continuously asserted until it is negated.

For a warm boot process, in FIG. 12(c) (which is similar to FIG. 12(b),the system-reset signal 1110 is asserted for Y milliseconds, wherein Ymay be any suitable time period. It is to be understood thatnotwithstanding that FIG. 12(c) illustrates that Y, their values may bedifferent depending on the application. For instance, warm bootprocesses may benefit from a reduced time Y since certain systemelements may not require initialization or since there are lesstransients within a system that is already powered (pre-chargedcapacitances and inductances).

In FIG. 12(d), the system processor clock generates the clock signal1206, which typically begins operation once the input power has reachedan acceptable operating level. While it is possible that the clocksignal 1206 is held in reset until the system-reset signal 1108/1110 isnegated, it is often preferable to allow the clock signal 1206 tooperate during the time interval X, (or Y) to aid the system logicand/or initializing the processor into a known state. For example, manygeneral-purpose processors and digital signal processors typicallyrequire a number of input clocks to properly operate when released fromthe reset state. It is to be understood that the clock signal 1206 isshown for pedagogical purposes and is not a required element of thepresent invention. Again, a maximum delay from reset negation to bootdevice availability may be implemented based on, e.g., a maximum numbern of clock cycles (or some other pre-specified time interval). Forexample, in the Personal Computer Interface Specification Revision 2.2,the boot device must be available 5 clock cycles after the negation ofreset on the bus, or the system may crash. At the current system clockrates of 33 and 66 megahertz, this approximately corresponds to maximumtimes of 150 and 75 nanoseconds, respectively. Again, the maximum delayfrom reset negation to boot device availability may be anywhere fromzero to some maximum specified time value delineated in any convenientunits including multiples of clock periods.

As further illustrated in FIG. 12(e), in a cold boot process, theboot-device-reset signal 1114 preferably follows thepower-supply-monitoring signal 1102, although this is not essential forimplementing a boot process according to this invention. With a warmboot process, the boot-device-reset signal 1114 will change from anegated state to an asserted state upon the system-reset signal 1110being asserted. When the system-reset signal 1108 is asserted to activelow, the boot-device-reset signal 1114 is asserted to active low for Zmsec, where Z comprises a number that is shorter than the respective Xor Y time periods for cold and warm boots respectively. In general, theperiod of time X-Z (or Y-Z with a warm boot) should be sufficient toload and activate the programmable logic device elements necessary forboot, which may comprise of a portion of one programmable logic deviceor one or more programmable logic devices. This time period may beshortened, for instance when reloading of the volatile logic device isnot necessary.

Further, an optional internal state machine is set to provide anindication of the mechanism that is responsible for initiating the bootprocess. Preferably, this mechanism comprises either asserting ornegating the cold-boot-flag indicator 1118 along with the complementarywarm-boot-flag indicator 1116. In particular, as shown in FIGS. 12(f)and (g), in a preferred embodiment, the warm-boot-flag indicator 1116and the cold-boot-flag indicator 1118 change state when theboot-device-reset signal 1114 is negated. It is to be appreciated thatin other embodiments of the present invention, the state machine andindicator signals may be valid earlier than negation of theboot-device-reset signal 1114, if so desired.

Referring now to FIG. 13, a plurality of timing diagrams are showndepicting both cold and warm boot process for implementation of the bootmanagement circuit 1100 in a non-legacy system. These timing diagramsare similar to the corresponding timing diagrams of FIG. 12, expect thatin FIG. 13, the system-cold-boot-reset-request signal 1104 in FIG. 13(e)and the commanded-warm-boot-reset-request signal 1106 signal in FIG.13(f) are utilized directly as the cold and warm boot requests, asopposed to their derivation in legacy applications as described herein.

Referring now to FIGS. 14a and 14b , flow diagrams respectfullyillustrate a “cold” and “warm” boot process according to one aspect ofthe present invention. More specifically, with a preferred cold bootprocess as illustrated in FIG. 14a , a test or other check iscontinuously performed to determine whether the power supply has beenturned on (step 1402). If power has been applied (affirmativedetermination in step 1402), a determination is then made as to whetheras to whether the voltage, current, and/or aggregate power from one ormore supply voltages has met a predetermined threshold (step 1404).Furthermore, in the case of under-damped or critically damped supplies,it may also be desirable to test both high and low voltage rails toensure that the power supply has settled. This process may also includea time delay to ensure that the supply is not in the process ofoscillating above and below the thresholds, inducing a false powersupply valid indication. Multiple senses (and the order thereof) may becombined to derive the most reliable or otherwise optimal indication ofpower supply validity, if so desired.

Upon power supply validity (affirmative determination in step 1404),preferably, two parallel processes occur (i.e., a first parallel processcomprising steps 1406, 1408, and 1410, and a second parallel processcomprising steps 1412, 1414, 1416, and 1418). More specifically, thefirst parallel process initiates with the system-reset signal 1108 beingasserted for X msec (step 1406), or some other prespecified time period.Then, after expiration of the time period X, the system-reset signal1108 is deasserted (step 1408). Then, a time delay 540 (shown in FIG.13(n) as n clock cycles) is optionally inserted before the boot process1420 begins.

In the second parallel process, the boot-device-reset signal 1114 isasserted (substantially concurrently with the assertion of thesystem-reset signal 1108) for Z msec (step 1412), wherein Z<X During thetime period Z, any logic devices utilized on the 15 boot storage adapteror processors may be reset including those utilized to load the volatilelogic device including the boot storage device. At the expiration of Z,the boot-device-reset signal 1114 is deasserted (step 1414). Then, theboot state indicator is optionally read to ensure the appropriate bootprocess and loading of the correct logic code into the programmablelogic device (step 1416). Next, the programmable logic device is loaded(step 1418). It is to be noted that a delay may then be encounteredwaiting for completion of the first parallel process. Finally, the bootprocess begins (step 1420).

With a preferred “warm” boot process as depicted in FIG. 14b , a test orother check is continuously performed to determine whether a request forreset (e.g., user, system, application, etc.) has been asserted (step1422). If so (affirmative determination in step 1422), two parallelprocesses occur (a first parallel process comprising steps 1406, 1408,and 1410, and a second parallel process comprising steps 1412, 1414,1416, and 1418). The first parallel process initiates with system-resetsignal 1110 (master reset) being asserted active low for time period ofY msec (step 1406), wherein Y may be equal to any suitable time period.After the system-reset signal 1110 has been asserted for theprespecified time period Y, the system-reset signal 1110 is deasserted(step 1408) and a maximum time delay of n clock cycles is optionallymandated (step 1424) for the availability of the boot device. The bootprocess begins (step 1426) if the boot device is available. In thesecond parallel processes, the boot-device-reset signal 1114 is assertedfor Z msec (step 1412), wherein Z<Y. After the expiration of Y, theboot-device-reset signal 1114 is deasserted (step 1414). Then, the bootstate indicator is optionally read to ensure the appropriate bootprocess and loading of the correct logic code into the programmablelogic device (step 1416). Next, the programmable logic device is loaded(step 1418). It is to be noted that a delay may then be encounteredwaiting for completion of the first process. Finally, the boot processbegins (step 1426).

FIG. 15 illustrates a schematic circuit diagram of a boot managementcircuit 1100 (FIG. 11) according to a preferred embodiment of thepresent invention. In the illustrated embodiment, the boot managementcircuit 1100 comprises a power supply sense circuit 1502 comprising aninput node A, a diode D1, resistors R1 and R4, a capacitor C1, a jumperJ1 and output node B. Preferably, R1 is at least one order of magnitudelower than the resistance R4. The power supply sense circuit 1502 isessentially a dual time constant integrator with R4 and C1 defining thecharge time constant and R1 and C1 defining the discharge time constant.While it is preferable that D1 have a low forward bias voltage such asthose found in Schottky diodes, it is not necessary as R4 bleeds outresidual charge at a low rate for voltages below and the forward bias ofthe diode D1 when the power supply sense voltage (at node A) drops belowthe forward bias of the diode D1. The jumper J1 may be used toshort-circuit the other components of the power supply sense circuit1502 to eliminate the effect of the charge/discharge time constants inthe event that the power supply provides the needed characteristics.

The boot management circuit 1100 further comprises a Schmidt inverterU1, operatively connected to the power sensor power supply sense circuit1502 at node B, and operatively connected to an input of a falling edgedifferentiator 1504 at node C. The falling edge differentiator 1504preferably comprises a capacitor C2 and resistor R2. The Schmidtinverter U1 is employed in conjunction with the falling edgedifferentiator 1504 to generate a pulse (at node D) that is utilized tocreate a boot-device-reset signal 1114 (at node E) by means of a twoinput Schmidt AND gate U2 (which operates as an active low in, activelow out, OR gate).

The boot management circuit 1100 further comprises a system resetcircuit 1506 comprising a jumper J2 and resistor R5, for processing thelegacy system-reset signal 1108/1110, a jumper J3 again with resistorR5, for processing the expansionbus-bus-rest signal 1112, and a jumperJ4 and resistor R6 for processing the commanded-warm-boot-reset-requestsignal 1106. By inclusion of jumpers J2, J3, or J4, and an appropriatelyasserted reset-request signal at the respective input, aboot-device-reset signal 1114 (at node E) will be generated. It shouldbe noted that each of the jumpers J1-J4 illustrated in FIG. 15 maycomprise any suitable conventional switching device, including, but notlimited to, passive or active, or static or dynamic, switching devices.When jumpers J2, J3 and J4 are not installed, resistors R5 and R6 areutilized as logic pull-ups to default the system and external resetrequests to the inactive state.

Next, an AND gate U3 is utilized to combine the system and user resetrequest signals into one combined request (output at node H). Adifferentiator circuit 1508, comprising a capacitor C3 and a resistorR3, acts as a rising edge differentiator whose output (at node I) isthen supplied to a Schmidt inverter U4 for waveshaping the reset requestpulse (output to node J). It is to be noted that the values of C3 and R3are preferably selected based on the desired pulse width time of thesignal output at node J. U2 is again utilized to logically OR thepower-up system reset, and external reset request. An SIR flip-flop U6implements a state machine that asserts and negates the appropriatewarm-boot and cold boot-flags, 1116, 1118. A Schmidt inverter U5 isutilized to convert the polarity of the power-up reset for appropriateoperation of the state machine. As previously noted, the ability for acomputer or computer appliance to inquire about the boot initiator isadvantageous, as it provides a mechanism for rebooting of only thosesystem and reloading of those programmable logic devices that arerequired or desired.

FIG. 16 comprises a plurality of timing diagrams illustrating the stateof the signals located at each node (A-J) of the boot manager circuitillustrated in FIG. 15. More specifically, the letter designations A-Jcorrespond to the waveforms generated as a function of time at theassociated nodes labeled in the schematic diagram of FIG. 15. Signal Aillustrates a typical turn-on transient of a power supply of a computeror a computer appliance. With computers comprising low cost switchingpower supplies that operate with the power consumption of hundreds ofwatts, this time is typically 5 msecs. This time and the actual profilevary significantly based on the design and individual system tolerances.It is expected that as power supplies continue to become more efficientand faster, the switching frequencies will increase causing a shortertum on profile. The present embodiment does not rely on any specifiedtime or wave shape for the tum on profile.

Further, Signal B depicts the voltage waveform input to U1 as generatedby Signal A (power supply sense input) charging the C1 with timeconstant R4C1. The Schmidt trigger U1 provides threshold hysteresis,affording a higher level of nose immunity. It is to be noted that U1 isnot a necessary component of the invention.

Signal C is the output of the Schmidt trigger inverter U1, and Signal Dis the output as processed the falling edge differentiator 1504. SignalD is input to the Schmidt AND gate U2 to generate the boot-device-resetsignal 1114 as illustrated Signal E. Signal D is also input to theSchmidt inverter US, which outputs Signal K. Signal K is input to S/Rflip-flop U6 which then sets the indicator cold-boot-flag indicator 1118shown as Signal L. The complementary output indicator warm-boot-flagindicator 1116 is simultaneously negated as shown Signal M.

The system-reset signal 1108/1110 and commanded-warm-boot-reset-requestsignal 1106 are shown disabled by the removal of jumpers J2 and J4,respectively. Both requests are shown active low and Signals F or G showindividual requests. The Schmidt AND gate U3 logically ORs the requestand generates Signal H as an input to the rising edge differentiatorcircuit 1508. The output of the differentiator circuit 1508, Signal I,is the input to Schmidt inverter U4 which generates signal J that isinput to both U2 and U6.

A boot-device-reset signal 1114 is then generated and the S/R flip-flopU6 is set to the warm-boot-flag indicator 1116 as indicated by Signal M.As before, the use of Schmidt function provides additional noise marginthrough the logic's hysteresis and is optional to all logic functions inthe present invention.

Although illustrative embodiments have been described herein withreference to the accompanying drawings, it is to be understood that thepresent invention is not limited to those precise embodiments, and thatvarious other changes and modifications may be affected therein by oneskilled in the art without departing from the scope or spirit of theinvention. All such changes and modifications are intended to beincluded within the scope of the invention as defined by the appendedclaims.

1.-20. (canceled)
 21. A system for generating a boot device resetsignal, the system comprising: a first node for receiving a power supplymonitoring signal; a second node for receiving a system cold boot resetrequest; and a power supply monitor dual time constant integratorcoupled to the first node; wherein the system is configured to: performa logical OR operation of an output signal of the power supply monitordual time constant integrator and the system cold boot reset request;and electrically differentiate the logical OR of the output signal ofthe power supply monitor dual time constant integrator and the systemcold boot reset request to generate an electrically differentiatedsignal.
 22. The system of claim 21, wherein the electricallydifferentiated signal is utilized to set a cold boot flag.
 23. Thesystem of claim 21, wherein the power supply monitor dual time constantintegrator comprises a single capacitor.
 24. The system of claim 21,wherein the power supply monitor dual time constant integrator comprisesa charge resistor and a discharge resistor.
 25. The system of claim 24,wherein the resistances of the charge resistor and the dischargeresistor are at least one order of magnitude apart.
 26. The system ofclaim 21, further comprising a differentiator for performing theelectrical differentiation, said differentiator comprising a capacitorand a resistor.
 27. The system of claim 21, wherein the power supplymonitor dual time constant integrator comprises a logical combination ofpower supply voltages to create a power sense signal.
 28. The system ofclaim 27, wherein the logical combination ensures that power has beenapplied in a proper sequence.
 29. The system of claim 27, wherein thecombination of power supply voltages includes one or more of: +5 volts,+3.3 volts, +1.8 volts, +1.5 volts, +12 volts, −12 volts.
 30. The systemof claim 21, further comprising a Schmidt trigger for providing noiserejection to the electrically differentiated signal.
 31. A method forcreating a boot device reset, the method comprising: performing alogical OR operation of a power supply monitoring signal generated fromthe output of the power supply monitor dual time constant integratorwith a system cold boot reset request; and electrically differentiatingthe logical OR of the cold boot system reset signal and the output ofthe power supply monitor dual time constant integrator.
 32. The methodof claim 31, wherein the electrically differentiated signal generatedfrom the logical OR of the cold boot system reset signal and the outputof the power supply monitoring dual time constant integrator is utilizedto set a cold boot flag.
 33. The method of claim 31, wherein the dualtime constant integrator utilizes a single capacitor.
 34. The method ofclaim 31, wherein the dual time constant integrator utilizes a chargeresistor and a discharge resistor.
 35. The method of claim 34, whereinthe resistances of the charge resistor and the discharge resistor are atleast one order of magnitude apart.
 36. The method of claim 31, whereinthe time constant to charge and the time constant to discharge the dualtime constant integrator are at least one order of magnitude apart. 37.The method of claim 31, wherein the differentiator is comprised of acapacitor and a resistor.
 38. The method of claim 31, wherein the powersupply monitor utilizes a logical combination of power supply voltagesto create a power sense signal.
 39. The method of claim 38, wherein thespecific logic combination ensures that the power has been applied inthe proper sequence.
 40. The method of claim 38, wherein the combinationof power supply voltages includes one or more of: +5 volts, +3.3 volts,+1.8 volts, +1.5 volts, +12 volts, −12 volts.
 41. The method of claim31, wherein a Schmidt trigger is utilized in conjunction with thelogical OR function for noise rejection.
 42. A method for creating anelectrical boot device reset, the method comprising: performing alogical OR of an optional system reset signal with an optional expansionbus reset signal and with an optional commanded warm boot reset request;and differentiating the logical OR of the optional system reset signalwith the optional expansion bus reset signal and with the optionalcommanded warm boot reset request.
 43. The method of claim 42, whereinthe differentiated logical OR of the optional system reset signal withthe optional expansion bus reset signal and with the optional commandedwarm boot reset request is utilized to create a boot device reset. 44.The method of claim 42, wherein the differentiated logical OR of theoptional system reset signal with the optional expansion bus resetsignal and with the optional commanded warm boot reset request isutilized to set a warm boot flag.
 45. The method of claim 42, whereinthe differentiated logical OR of the optional system reset signal withthe optional expansion bus reset signal and with the optional commandedwarm boot reset request is utilized to create a boot device reset andset a warm boot flag.
 46. A boot management circuit comprising: a set ofone or more inputs, each input operable to provide to the bootmanagement circuit a signal selected from a power supply monitoringsignal, a system cold boot reset request signal, a commanded warm bootreset request signal, a system reset signal, or an expansion bus resetsignal; and one or more of a boot device reset signal output, a systemreset signal output, a warm boot flag signal output, or a cold boot flagsignal output, wherein the boot management circuit is operable toprovide an indication of at least one of: a cold boot request at thecold boot flag signal output based on receipt of at least one of thepower supply monitoring signal or the system cold boot reset signal, awarm boot request at the warm boot flag signal output based on receiptof a commanded warm boot request signal, a cold boot request at the coldboot flag signal output based on receipt of either the system resetsignal or the expansion bus reset signal, and further based on the powersupply monitoring signal being below a threshold value, or a warm bootrequest at the warm boot flag signal output based on receipt of eitherthe system reset signal or the expansion bus reset signal, and furtherbased on the power supply monitoring signal being above the thresholdvalue.
 47. The boot management circuit of claim 46, further comprising:a power supply sense circuit for receiving the power supply monitoringsignal; a first logic device operable to output a logical OR of anoutput of the power supply sense circuit and the system cold boot resetrequest signal; and a first differentiator for receiving the outputlogical OR and for generating a pulse for creating the boot device resetsignal.
 48. The boot management circuit of claim 47, wherein the powersupply sense circuit comprises a dual time constant integrator having afirst capacitor and a first resistor that establish a charge timeconstant, and having a second resistor, that, with the first capacitor,establishes a discharge time constant.
 49. The boot management circuitof claim 47, wherein the second resistor is at least an order ofmagnitude lower than the first resistor.
 50. The boot management circuitof claim 48, wherein the power sense circuit includes a jumper forbypassing the dual time constant integrator.
 51. The boot managementcircuit of claim 47, wherein the first logic device is a Schmidt ANDgate.
 52. The boot management circuit of claim 47, further comprising: asystem reset circuit having a first node for outputting the system resetsignal or the expansion bus reset signal and having a second node foroutputting the commanded warm boot reset request signal; a second logicdevice operable to output a logical OR of signals at the first andsecond nodes; and second differentiator for receiving the output logicalOR of the signals at the first and second nodes; and a third logicaldevice operable to output a logical OR of the first and seconddifferentiators.
 53. The boot management circuit of claim 52, furthercomprising a flip-flop for receiving outputs of the first and seconddifferentiators and generating signals at the warm boot flag and coldboot flag signal outputs.
 54. The boot management circuit of claim 47,wherein the power supply sense circuit is configured to sense powersupply voltages selected from one or more of: +5 volts, +3.3 volts, +1.8volts, +1.5 volts, +12 volts, and −12 volts.